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Abstract — This paper describes concepts for secure naming 
and addressing directed at Store, Carry and Forward (SCF) 
distributed applications, where disconnection and intermittent 
connectivity between forwarding systems is the norm. The 
paper provides a brief overview of store, carry and forward 
distributed applications followed by an in depth discussion of 
how to securely: create a namespace; allocate names within the 
namespace; query for names known within a local processing 
system or connected subnetwork; validate ownership of a given 
name; authenticate data from a given name; and, encrypt data 
to a given name. Critical issues such as revocation of names, 
mobility and the ability to use various namespaces to secure 
operations or for Quality-of-Service are also presented. Although 
the concepts presented for naming and addressing have been 
developed for SCF, they are directly applicable to fully connected 
systems. 

Index Terms — Internetworking, Mobile ad hoc networks, In- 
formation Security 

I. Introduction 

I NTERNET technology has become pervasive and is now 
present in many types of devices that are deployed in 
the field for use in scenarios where they do not have good 
(or any) actual Internet connectivity. The devices support data 
transfer during episodes of connectivity, and the applications 
and protocol are configured to avoid reliance on many typical 
infrastructure services (e.g. Domain Name System (DNS)). 
These devices may be only intermittently connected to other 
devices, and are used to support data flows where the source 
and ultimate destination might never be fully connected to 
one another at any time. Applications operate highly asyn- 
chronously, with incalculable constraints on their communica- 
tion. Often, there are intermediate relaying nodes (or “agents”) 
that must “carry” the data while waiting for connectivity to 
develop. The systems and applications that are of concern are 
primarily operating with a much higher level of asynchrony 
between the data producers, individual relays, and eventual 
data consumers. We call these “Store, Carry, and Forward” 
(SCF) systems to distinguish them from typical Store and 
Forward (SF) systems, which generally operate over a better- 
connected infrastructure [1][2]. 

SCF distribute applications can be thought of as an extreme 
case in Mobile Ad Hoc Network (MANET) because discon- 
nection and intermittent connectivity is the assumed condition 
whereas in mobile ad hoc networking hop-by-hop connectivity 
is generally assumed. Fig. 1 illustrates a generic SCF network 
architecture, with the SCF agents (labeled “SCF”) frequently 
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Fig. 1 . MANET and Store, Carry and Forward Networks 

partitioned into time-varying disconnected subsets. Depending 
on specifics of an individual scenario, it may be likely that 
some SCF agents are permanently attached to a connected 
network providing stable gateways to the other SCF agents. 
However, in general, the system should be considered to 
consist of a number of primarily intermittently connected SCF 
agents at any point in time. 

There are numerous lessons to be learned from previous 
deployments of MANETs and store and forward networks 
such as Delay/Disruption/Disconnection Tolerant Networking 
(DTN) [3][4][5][6]. Since SF and DTN networks have no real 
bounds relative to the maximum time an identified data or 
control unit can exist within a routed network, SF and DTN 
are really distributed applications [7]. Regardless, some of the 
more critical items are: 

• SCF systems are generally connected via radio networks. 
Some radio systems may take far less power to listen 
than to transmit, though this varies by individual link 
technology. Unnecessary transmission wastes power on a 
wireless system and can quickly drain a battery. The prob- 
lem is compounded for devices whose entire lifetime is 
determined by their battery (e.g. non-rechargeable sensor 
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nodes). Thus, reducing the number of transmissions is 
very important. 

• It is highly desirable for the sender to know early in a 
transmission whether or not the receiver will accept the 
data, and likewise for the receiver to be able to make this 
decision early within a transfer. This permits a savings 
in power and optimization of network capacity usage. 
For instance, in DTN experiments with large bundles, an 
entire large bundle may be sent, only to be discarded due 
to receiver policy for security, resource scarcity, or other 
issues. 

• Disconnected and intermittently connected networks are 
difficult, if not impossible, to globally synchronize state 
across - particularly achieving even rough global time 
synchronization is a challenge. Timer based mechanisms 
can be used without requiring global time synchroniza- 
tion. Tight time synchronization is seldom necessary 
and should be avoided in any distributed system as it 
introduced a single point of failure. 

• It is highly desirable for a receiving agent to determine 
early within a transfer whether or not to accept the data. 
Large data sets utilize significant processing and storage 
resources for data that may end up being discarded due 
to security, resource constraints, or other policy issues. 

• It is highly desirable to have some way to establish single- 
copy routes rather than flooding entire networks with 
multiple copies of the same data. 

• Communications and mobility is not completely random 
even for ad hoc networks. 

• As one moves father from the core (backbone) of the 
network, nodes generally have less connectivity and ca- 
pability. 

A. Terminology 

To aid in discussion within this document it is useful to 
develop and define some terminology specific to our concepts 
of SCF networks. 

Container The application/user data to be trans- 

ported over the network as well as a 
checksum of that information (the pay- 
load). 

Shipping Label Metadata describing the characteristics of 
a container and its forwarding require- 
ments (the header). 

II. Namespaces (Naming and Addressing) 

The conclusion goes here We draw much of our concepts 
for naming and addressing from three source: “Patterns in Net- 
work Architectures” [8], “A note on Inter-Network Naming, 
Addressing, and Routing” [9], and “On the Naming and Bind- 
ing of Network Destinations” [10]. In particular, Saltzer [10] 
provides a summary of services, nodes, and attachment points 
that, if strictly followed, enables: services (a.k.a. applications) 
to be distributed and/or move, multi-homing of nodes, and 
mobility. 


1) A given sendee may run at one or more nodes, and may 
need to move from one node to another without losing its 
identity as a service. 

2) A given node may be connected to one or more network 
attachment points, and may need to move from one 
attachment point to another without losing its identity 
as a node. 

3) A given pair of attachment points may be connected by 
one or more paths, and those paths may need to change 
with time without affecting the identity of the attachment 
points, [sic] 

Saltzer also points out that three sets of bindings must 
be maintained and must be discovered in order to send 
information between services: 

• The binding between the service and the node it at which 
it resides; 

• The binding between the node and the network attach- 
ment point (or points, if multi-homed); and, 

• The path from source attachment point to destination 
attachment point (routing) 1 . 

For our discussions, we are not concerned with the bindings 
of attachment points (i.e. routing). Rather, we consider two 
basic forms for names: locators and identifiers. 

Locators (a.k.a. addresses) are hierarchical, at least that is 
highly desirable in order to aid in routing as agents need 
some clue about where to send containers in order to get 
“closer” even if they do not know the best direct path. For 
example, to send information from 1600 Pennsylvania Avenue 
NW Washington, DC to 10 Downing Street, London, England, 
United Kingdom one knows that sending the information to 
somewhere in the United Kingdom is getting that information 
closer to the final destination. Likewise, in a tree-based hier- 
archical numbering system, if information is to be transferred 
from 1.2. 3.4 to 1.2.100.87, sending the information towards 
a grandparent node, 1.2, should be getting the information 
“closer” to the destination or at least to a node that likely has 
a better idea of where 1.2.100.87 is. 

Identifiers are not necessarily hierarchical, and may or may 
not be human readable. Identifiers should be unique and 
are used to identify applications or services. Identifiers are 
bound to locators and discovered via some type of directory 
service. This binding may change over time. In SCF distributed 
applications where disconnection is assumed to be normal, 
distribution and synchronization of these directories required 
for discovery must be well thought out. Directory services are 
discussed further in section 11. 

III. Philosophy of Multiple Namespaces 

In the Internet, there is one namespace, Internet Protocol 
(IP) addresses for routing. The World Wide Web contains 
Uniform Resource Locator (URL) for high for higher-level 
identifiers. The Domain Name System (DNS) directory pro- 
vides a directory service for mapping computers, services, or 
any resource (e.g. email. Unique Resource Locator for Web 

'Whereas, here, Salzer defines routing as between attachment points, we 
consider routing between source node and destination node as a node may 
have multiple points of attachment i.e., multi-homing. 


NASA/TM— 20 1 4-216665 


2 


services, etcetera) connected to the Internet. (Arguably, Inter- 
net Protocol version 6 (IPv6) can support multiple namespaces 
e.g. Global Unique Address (GUA) for normal routing and 
ORCHID [11] for higher-layer identifiers, but this facility 
has not been strongly used, nor will it be easy to, given the 
way that existing software and hardware works, basically only 
supporting their known subsets of existing type prefixes, and 
not new prefixes). For SCF, we are proposing a system of 
unlimited namespaces, which can be used to construct either 
pools of application identifiers without mandated structure, or 
pools of addresses with hierarchical structure. Thus, here, the 
only difference between addresses and other identifiers is their 
hierarchical nature. 

The limitation of one namespaces, and the global visibility 
of that namespace to applications, is a root cause of many 
complexities and fragilities within today’s Internet architec- 
ture, including within: the interdomain routing system, the 
DNS, IP neighbor discovery, and other aspects. This has 
led to a multitude of security issues related to not being 
able to verify ownership of particular identifiers or addresses, 
and not being able to authenticate the bindings between 
particular identifiers and addresses. These issues have, to some 
extent, been attempted to patch over with BGPSEC/SIDR [12], 
DNSSEC [13], SeND [14], and other extensions, but these 
have shifted the security issues to issues of increased opera- 
tional and infrastructure complexity. Both of the namespaces 
still have centralized (though hierarchical) allocation and man- 
agement at the top (e.g. IANN, ICANN, RIRs). There are 
no real mechanisms available for creating new namespaces, 
as even with IPv6, the 128-bit fields have been fixed and 
follow formats with prefixes that Internet Assigned Numbers 
Authority (IANA) defines. 

One of the most significant new facets of this SCF proposal 
for namespace security is that rather than living within existing 
namespaces, or subsets of them, we are allowing the creation 
of an infinite number of new namespaces, and to do so with 
minimum effort and quickly. Communication is only possible 
between nodes that have consented to join a given namespace, 
so though a node may create its own namespace, this will be 
worthless unless other nodes have policies that allow them to 
become enrolled within the new namespace. Although similar 
in concept to Virtual Private Networks (VPNs), the SCF 
namespaces are more powerful for several reasons, including 
(1) wider scope compared to VPN prefixes, (2) less brittle 
configuration and potential for negative interaction with other 
portions of a host Operating System (OS) networking stack, 
and (3) better integrated with identifier-address resolution 
mechanisms, preventing issues of confused scope that occur 
in VPNs. 

SCF’s multitude of namespaces also differs very signifi- 
cantly from the Internet, as nodes that do not participate in 
IP addressing are completely unreachable, and nodes have a 
relatively poor and unclear granularity in terms of whether 
they’re privately reachable [15] versus using globally routable 
addresses. Furthermore, the lack of security in the IP names- 
pace, allows visible and invisible proxies. Network Address 
Translators (NATs), and other middleboxes to subvert the roles 
and identities of end-nodes in communication flows, without 


explicit consent, and this brutality is really the only way 
to grow the Internet and add new features because of the 
limitation of the single IP namespace. 

In summary, the traditional approach to networking in 
today’s Internet is to build one big layer-3 network and then 
deploy firewalls and VPNs throughout until one deems the 
network secure. Unfortunately, the configuration becomes so 
baroque that it will almost certainly break eventually. Our 
approach is to use credentials to build pair wise relations 
with neighbors or end-to-end peers, and to verify hosts and 
data prior to committing resources. No firewalls, VPNs, etc. 
are required in order to implement the policies and security 
postures desired. Rather, the architecture is actually just secure 
by design. 

IV. Creating a Secure Namespace 

To mitigate potential threats to network, data, and applica- 
tion security SCF needs ways for: 

• Applications (end-applications and agents) to validate 
received data 

• End-applications to protect transmitted data 

• Agents to validate end-applications that attempt to utilize 
them 

• Agents to validate one another when in contact 

Application of namespaces will enable these capabilities. 

In a secure namespace, a root server exists somewhere 

in order to keep a database of registered names within the 
managed namespace, and to issue certificates when names 
are allocated from the namespace. Once allocated, a name 
should never be de-allocated or reused, since the lifetime of 
containers/labels with the name may be unbounded (however, 
names may be revoked). The root certificate for namespace 
X, called the Name Space Identifier (NSI) certificate, needs 
to be installed on systems hosting applications that will 
use or (securely) process containers/labels with names from 
namespace X. The NSI contains a public key for the root, and 
optionally a description of the valid name formats within the 
namespace (e.g. via a regular expression), along with optional 
metadata. The root certificates are the only trusted components 
of the system. 

Given that SCF supports a multitude of namespaces, in 
order to be implementable and deployable, the format needs 
to be bounded. We propose to uniquely indicate namespaces 
through the use of Universally Unique Identifierss (UUIDs) 
created by the “namespace owner”. These UUIDs can follow 
the format defined in RFC 4122 [16], which supports 128-bit 
UUID constructed from a timestamp, sequence number, and 
spatially unique node identification. 

Since we recognize that time synchronization in SCF net- 
works is difficult, and that even remembering the current 
time across boot-ups may be difficult for some nodes, we are 
initially using RFC 4122’s version 1 form of UUIDs, where 
the timestamp is made robust to such issues via scoping it 
within the other fields. In this form, the sequence number can 
either be recorded between boots, or generated randomly (or 
pseudo-randomly), and where the node identification comes 
from either Institute of Electrical and Electronics Engineers 
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Fig. 3. Creating Proof-of-Names 


Fig. 2. Creating a Namespace 

(IEEE) Media Access Control (MAC) addresses or a self- 
generated value. One downside to this form of UUIDs is that 
they are not human-readable or otherwise indicative of the 
namespace’s purpose. Whether this is a downside in practice 
or not needs to be determined through further experimentation 
and deployment experience with SCF-based networks. We 
suspect it may not be an issue, as a database service mapping 
UUIDs to human-meaningful strings could be created, as well 
as preconhguring applications with the UUIDs of namespace 
they need to operate within so that the UUIDs themselves are 
not user- visible. 

Once the UUID has been selected, the namespace owner 
will associate it with a public/private keypair by creating a 
certificate called the Name Space Identifier (NSI) [Fig. 2]. 
This certificate holds fields for the UUID and public key, and 
is signed using the private key. Of course, the details of the 
certificate format and the cryptographic algorithms chosen are 
of interest, and those are addressed in section 6, Certificate 
Details. 

The namespace owner is now responsible for managing 
a database recording any names that it has granted. The 
basic schema for this database needs to include a sequence 
number, the allocated name itself (an arbitrary string of bits), 
a public key from the node that the name was allocated to, 
and potentially timestamps associated with the name creation 
and/or expiration. 

At this point, the namespace has been created, and the 
namespace owner can serve requests for allocating names, as 
described in the next section. 

It is imperative to understand that in order to be a user of this 
namespace, the user must obtain a copy of the NSI certificate. 
This could be done in a number of ways. The key question 
is how is this bootstrapped, how does the initial creation and 
distribution of the NSI work in a practical deployment? One 
method that is highly likely - particularly for SCF networks 
consisting of sensors - is that an entity is populated with at 
least one NSI during pre-deployment or even as part of the 
manufacturing process. For other types of applications (that 
build overlays for instance), the NSI could be installed when 
the application is installed. Also, application software could 
support importing NSIs retrieved from a web server or in 


some other way, similar to the way the Peer-to-Peer Session 
Initiation Protocol (P2PSIP) Distributed Hash Tables (DHTs) 
are configured [17]. Without an NSI, a system cannot validate 
any names within that particular namespace associated with 
that particular NSI. 

V. Allocation of Names 

We need a mechanism to secure and validate names and 
applications. We propose to support this by using simple 
certificates called Proof-of-Name (PoN) certificates, related 
to NSI certificates. How an application receives its names 
is highly dependent on the operational environment. In some 
cases, this may be totally pre-configured and statically setup, 
requiring no direct real-time contact with the root of the 
namespace. In other cases, applications may be able to dynam- 
ically receive PoN certificates during a time of connectivity 
to the root. The following describes the procedures to obtain 
and allocate validated names from the perspective of the name 
requester. 

The name requester wishes to obtain a name from the 
namespace owner to be used as a secure identifier. In order to 
do so, the requester needs to obtain a PoN certificate from the 
namespace owner. The requester either asks for a particular 
name (identifier) explicitly or allows for an owner-selected 
name. The requester supplies its public key (described in 5.1). 
The namespace owner either checks its database to see if the 
specific name is available or generates an unambiguous name 
per the request. The namespace owner enters the name into 
the database and marks it as in-use, storing the public key 
and returning a PoN certificate for the name, signed by the 
namespace owner [Fig. 3] 

Names may be hierarchically assigned by the owner, sup- 
porting addressing as just another type of namespace that 
happens to have structure. A request can also be issued to 
request a batch of names (a delegated-subnetwork-namespace); 
this allows for secure prefix-delegation in an addressing system 
from the namespace owner. In this case, there is a slight 
modification to the basic operations using a Hierarchical 
Proof-of-Name (HPoN) certificate: 

• The HPoN certificate’s name field needs to indicate a 
range of names that have been allocated, rather than a 
single name. 
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• The namespace owner’s database needs to handle ranges 
of names. 

• All HPoN certificate holders become namespace owners 
and need to hold their own database of any PoNs or 
HPoNs they grant within the delegated subset of the 
namespace. 

• When HPoN certificates are given out from the subsets 
of the namespace (below the top-level), they include a 
copy of the upper-level delegated-subnetwork-namespace 
owner’s PoN as well. This is needed in order to validate 
the HPoNs using (and trusting) only the NSI certificate. 

A. User Key Pairs for Requesting Names 

The public key used for requesting a name could be from an 
existing keypair, or one that is generated just for the purpose 
of use with that name. It all depends on the situation and 
operational environment. For instance, if privacy/anonymity 
is a concern, a brand new keypair could be generated to use 
with an ephemeral name, and everything would be disposable. 
If access control to the namespace is an issue, keys that 
are already in-use and vetted somehow (e.g. through being 
present in a Personal Identify Verification (PVI) card Public 
Key Infrastructure (PKI) system) could be used. 

In general the source of key material should not matter 
to the naming system. However, there will definitely be 
some expectations on the sources of key material for specific 
applications creating and using the namespaces. 

VI. Certificate Details 

The certificates in our secure naming system are not X.509 
certificates [18]. Rather, they need to be much simpler in 
order to only support the profile of fields that is required for 
secure naming and reduce processing requirements and code 
footprint, as well as certificate size. 

NSI certificates include the following information 

• Namespace UUID 

• Public key of namespace-holder 

• Signature from namespace owner 

• Optional Fields: 

- Cryptographic Algorithm(s) used 

- Additional Serial (Sequence) Number 

- Regular Expression for names within the namespace 

- Creation Timestamp (rather coarse to be useable in a 
SCF network) 

- Expiration Timestamp (rather coarse to be useable in 
a SCF network) 

PoN certificates only need to include the following infor- 
mation: 

• Namespace UUID (matching the NSI) 

• Name granted 

• Public key of name-holder 

• Signature from namespace owner 

• Optional Fields 

- Serial (Sequence) Number 

- Creation Timestamp (optional and likely not readily 
useable in a SCF network) 


- Expiration Timestamp (optional and likely not readily 
useable in a SCF network) 

Numerous cryptographic algorithms are available for gen- 
erating the needed keypairs, digital signatures, etc., as well as 
specifications for certificate encoding and other aspects. The 
NSI certificate can indicate which cryptographic algorithms 
are to be used for operations within the namespace. This 
provides the namespace owner with the freedom to pick any 
sets of cryptographic algorithms, and optionally include them 
within the NSI. This information is only optional because 
in some highly embedded systems it may be fixed to the 
limited capabilities of the particular devices and statically pre- 
configured or otherwise known rather than a matter of choice. 
Due to nature of SCF and design principles of SCF, the need 
to Keep It Simple, in initial experiments we are using only one 
public key crypto suite (Elliptic Curve Cryptography (ECC) 
per National Security Agency (NSA) Suite B with 256-bit 
prime modulus Elliptic Curve Diffie-Hellman (ECDH) and El- 
liptic Curve Digital Signature Algorithm (ECDSA); one block 
cipher (Advanced Encryption Standard (AES)-128 Counter 
encryption mode (CTR)); and, one hash algorithm (Secure 
Hash Algorithm (SHA)-256), but other deployments can pick 
different algorithms while supporting the same concepts. 

Names and namespaces could have an expiration date, 
but supporting this goes back to the time synchronization 
requirement that SCF needs to avoid. However, for SCF 
distributed applications, time-synchronization could be much 
’rougher’ than today’s connected systems. 

The serial number and timestamp fields in the NSI are 
optional they may be redundant with the fields within the 
UUID, if the lengths there are sufficient. 

The secure namespace concepts presented here are agnostic 
to the concrete encoding of certificates as they are stored and 
exchanged. However, in any practical use of these concepts, 
concrete formats need to be defined. For our experiments, 
involving small systems such as in space exploration and 
sensor nodes, with no tolerance for extraneous code, we 
believe that X.509 certificates carry far too much baggage 
that isn't strictly necessary. We are instead experimenting 
with JavaScript Object Notation (JSON) objects that hold the 
necessary fields, and are rather easy to parse and generate with 
very small amounts of code. 

A. Certificates and Name Revocation 

Once issued, an attacker that obtains the corresponding 
private key could maliciously use an SCF PoN certificate. This 
is obviously a problem for distributed applications operating 
over intermittently connected and disconnected networks, as is 
the time to notify is unbounded and in the extreme is infinite. 
However, that do not mean one cannot attempt to mitigate the 
problem. 

Two ways that this can be mitigated are through flooding of 
Certificate Revocation Lists (CRLs) when the compromise of 
the public key is suspected, and through using lifetimes on the 
certificates designed to expire before the private key is likely 
to be compromised. The downsides to flooding CRLs is that it 
takes memory, network capacity, and time which will all be at 
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a premium in the use cases SCF is desired for. The downside 
to expiration times is that using them requires at least rough 
synchronization of distributed system clocks. 

As stated previously, it is difficult to synchronize state 
across SCF - particularly time. Because of this, traditional 
PKI techniques for revoking certificates (and names) cannot be 
used. Flowever, to provide some benefits, time-synchronization 
may only need to be to a coarse granularity of, for instance, 
a day. Even that may be non-trivial, in some systems (e.g. 
across reboots). Regardless, we suggest that other methods 
are possible. 

Without needing other nodes to understand an absolute 
expiration time, the namespace owner can simply revoke 
certificates when it unilaterally decides the expiration time has 
been reached. Because the NSI and PoN certificates have serial 
numbers, and because certificates within the same namespace 
should typically be expiring in sequence, this can be exploited 
in a sort of CRL compression method. For example, a rather 
small revocation message could be flooded containing only the 
serial number of the lowest unexpired PoN within a namespace 
or NSI generated by the owner. This would be signed with 
the owner’s private key. On reception, nodes would be able to 
store only this sequence number and know that any certificates 
below it are no longer valid. This implements a sort of rolling 
window of valid certificates advanced by the owner. 

In exceptional cases where the namespace owner needs 
to revoke certificates prior to natural expiration (e.g. in the 
case of compromise), a set of additional revoked sequence 
numbers can be appended to the flooded message. As such 
incidents will hopefully be significantly more rare than natural 
expiration, and as once natural expiration is reached, these 
special case revocations become subsumed by the advancing 
minimum valid sequence number, we believe this stands a 
good chance of working quite well in practice. 

Note that having the namespace owner announce revoca- 
tions in this way does not prevent further mechanisms from 
being incorporated into implementations in order to support 
more timely responses to incidents known within disconnected 
pockets of the network. For instance, it may be useful in some 
environments to be able to blacklist given names if there’s 
confidence that they’ve been compromised through some other 
means (like localized Host or Network Intrusion Detection 
Systems), even prior to a CRL being obtained that covers them. 

It is important to note the following two items regarding 
SCF certificates: 

• Since time-synchronization cannot be assumed, the cer- 
tificates do not strongly support non-repudiation; and, 

• A namespace owner destroys the namespace if it revokes 
its own NSI certificate, only if notice of that revocation 
reaches all nodes, and is remembered by them (e.g. not 
forgotten about after a reboot). 

In this secure naming system, it is currently much easier to 
create namespaces and names than it is to effectively destroy 
them. This may be a fruitful area of future work. 

VII. Discovering and Querying Names 

Creating a namespace and allocating names within it are 
necessary but not sufficient to enable communications. There 


needs to be a way for the names of reachable nodes and 
applications to be discovered and mapped into lower-layer 
protocol details in order to establish communications. This 
is provided through a generic directory service. This does 
not assume or imply that the addresses are exposed to the 
applications. Rather, this is the binding between the service 
e.g., application, and the node it at which it resides. That 
directory service can be implemented in a number of different 
ways, all optional for a given use of secure namespaces, and 
all requiring some further concrete details. These discovery 
mechanisms are specific to the given lower-layer protocols that 
secure namespaces are being built on top of in an application. 

The namespace owner already maintains a database of the 
granted certificates, so it seems natural at first to also use 
that database for directory services by enhancing it with 
lower-layer locators for the granted names. This clearly has 
scalability issues, since we have not yet defined a way to 
distribute the namespace owner role within a namespace. It 
also would only be useful in scenarios where nodes have 
frequent connectivity that allows communications with the 
namespace owner in order to query and update records as 
their lower-layer locators change. Clearly it is not a complete 
workable solution for SCF distributed applications. 

Another approach is to define neighbor discovery mecha- 
nisms similar to those used in IPv6., which will make use of 
lower-layer multicast/broadcast capabilities in order to learn 
about the nodes and applications that are available within the 
local scope of the lower-layer protocols. This is relatively 
easy to do by adapting the formats, timers, and algorithms 
that IPv6 neighbor discovery uses, and simply replacing the 
address fields with secure name fields. In contrast to IPv6 
Secure Neighbor Discovery (SeND), however, our secure 
namespace concept allows much easier proof of ownership 
to be demonstrated (see section 9). Establishment of neigh- 
bor relationships allows communications to be secured with 
the obtained credentials, optionally providing authentication 
and/or privacy services for future exchanges. 

A neighbor discovery based approach for learning name 
bindings is likely to work better in most SCF scenarios than 
a centralized database. However, the neighbor discovery only 
works within the scope of a single lower-layer hop. It does not 
support multi-hop forwarding or discovering the bindings for 
names that are owned by nodes that are multiple hops away 
within the underlying network. For this, multiple approaches 
can be made to work, including adaptation of existing routing 
algorithms and protocols such as Trickle [19] or IPv6 Routing 
Protocol (RPL) [20], adaptation of resource-locating protocols 
like Application-Layer Traffic Optimization (ALTO) [21], or 
developing a gossiping query protocol. In fact, different SCF 
scenarios that we have defined are certain to drive alternative 
approaches for this part of instantiating the secure naming 
concepts within a concrete system. This is an area where 
the most future work is needed in the near term; however, 
we believe it can be done largely using existing protocols as 
models or frameworks. In section 11, Directory Services, we 
provide some notional deployment scenarios for Directories. 
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VIII. Validating Name Ownership 


Relay/Mule 


Given that the NSI for a namespace is generated by the 
owner and distributed to any applications that will be working 
within that namespace, all applications are guaranteed to have 
the public key of the namespace owner, and be able to check 
signatures generated using the owner’s private key. Since the 
owner’s private key is used to sign the PoN certificates, any 
PoN certificates received from other applications can be easily 
validated, without resorting to cumbersome certificate chain 
operations normally involved in PKI-based systems. 

This only proves that the PoN certificate is legitimate and 
that the name has been issued; it does not prove that the 
application providing the PoN indeed holds the private key 
associated with the public key, nor does it prove that the name 
has not been revoked for some reason. 

Proving ownership of the name within the PoN can be done 
in two ways: 

1) Via a challenge-response exchange, in which the verify- 
ing party encrypts a puzzle with the public key from the 
PoN, and awaits a response that could only be gener- 
ated through decrypting the puzzle, thus demonstrating 
possession of the private key. 

2) Via a signature using the corresponding private key and 
covering the PoN plus some nonce like a timestamp, 
sequence number, or other freshness indicator that is 
bootstrapped out-of-band in a way that prevents replay 
attacks. 

The first method is relatively straightforward but requires 
both parties to be “online” or with direct low-latency commu- 
nication, otherwise much time and the corresponding oppor- 
tunities for communication may be wasted. 

The second method is more complex, and requires some 
help or support from the lower-layer protocols in order to 
provide the means to indicate freshness of a signature; possibly 
requiring time synchronization. The significant advantage of 
this method is that it can potentially be done one-way (without 
bidirectional exchange) and thus may be more amicable to 
scenarios where there is only unidirectional connectivity, high- 
delays, or lack of concurrent end-to-end paths. 

IX. Authenticating and Encrypting 

Authenticating and encrypting data to a given name is a 
relatively straightforward process. To authenticate data (the 
container), the sender signs the data using the private key 
corresponding to the public key in the sender’s PoN. The 
receiver then uses the PoN public key to check the signature 
and (if necessary) validates the PoN using the appropriate 
NSI certificate [Fig.4], Similarly, to encrypt data, the sender 
uses the public key in the destination’s PoN to encrypt data. 
The receiver then uses the private key portion of the keypair 
identified in its PoN in order to decrypt the data it receives. 

For SCF networks, it is highly desirable for a receiving 
agent to determine early within a transfer whether or not to 
accept the data in order to maximize resource utilization (e.g. 
bandwidth, storage, computation, battery). Thus, the ability to 
authenticate the data source is imperative. If the SCF protocol 
is designed in a matter to allow the shipping label to be 


Data 

Source 1. Send PoN 



3 Send Signed Containers 

<•••« 


2. Use NSI to 
Validate PoN 

NS '.. 


Fig. 4. Authenticating Names 


processed separately from the container body, the label can 
be authenticated efficiently within the network precisely in 
the same manner as the complete container’s data. 

X. Applications and Namespaces 

All applications need to have an Application Process Name 
(APN) that identifies them. Some APNs can be Distributed 
Application Namess (DANs) in order to support multicast style 
delivery, but in the basic case, an APN uniquely identifies a 
single process, and DANs are an advanced topic, beyond the 
scope of this paper. 

SCF agents are applications that parse labels and relay 
containers for other applications. SCF agents have APNs 
drawn from a namespace that identifies them as relaying 
applications. It is assumed that the applications (including SCF 
agents) share the same set of NSIs in order to be able to 
communicate within a namespace. 

How the application receives an APN, was covered in sec- 
tion 5, Allocation of Names. For now, assume the application 
knows about its APN, and has a certificate to prove that 
the APN was assigned from a root for the namespace. The 
application should internally posses the private key, which 
corresponds to the public key within its PoN certificate. This 
allows the application to prove ownership of the APN to 
any SCF agents or other SCF applications within the same 
namespace. 

A. Suggested Application Program Interface (API) based on 
APNs 

Applications use SCF via an API that can be system/vendor 
dependent. SCF agents can be within the same platform as 
applications or remote; the API is all that matters. An example 
API is shown below: 

• Poll for any SCF agents or SCF applications directly 
known to the local system. The SCF agents in the network 
may be using a beacon process to broadcast their pres- 
ence, may be statically configured on systems, or may be 
discovered through some other type of dynamic process. 
It does not matter to the application. When polling, the 
application’s APN should be provided, since some SCF 
agents may only have access controls that permit specific 
APNs to utilize them, and are not generally available to 
relay for all applications. This polling should return a 
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list of APNs that identify the SCF agents. There might 
be two flavors of polling; one that returns immediately 
with currently known information, and one that blocks 
while some on-demand results are collected by the local 
system; not all systems need to support both. 

• Register the application’s APN with a particular SCF 
agent. This should block and return success/failure. Reg- 
istration may allow the application to reserve space on 
the agent for incoming/outgoing containers. 

• Send a container via a SCF agent the application is 
registered with. The send call should include some way 
of ’signing’ the request, so that the SCF agent can authen- 
ticate it before committing resources for the container. 

• Receive a notification from a SCF agent the application is 
registered with that a container has arrived for the APN, 
giving relevant label material to the application. 

• Request a given container’s contents from the SCF agent. 

• Withdraw/destroy a registration with a SCF agent. This 
needs to be authenticated. 

It is important to note that the secure namespace operations 
allow all of these functions to be performed in a robust manner 
that protects both the network infrastructure and resources 
(buffers, bandwidth, etc), as well as the nodes and applications 
themselves. This is a significant difference from other store - 
and-forward systems that have been built (e.g. based on DTN) 
with similar APIs between relays and applications, but without 
the strength of any security to the namespaces involved. 

B. Addressing and Routing Application 

The following demonstrates how naming is used by applica- 
tions to communicate with one another and with SCF agents, 
without having addressing information visible. 

Advertising reachability of APNs between SCF agents can 
be done securely, if, when registering, the application provides 
a copy of its APN ownership certificate embedded in another 
certificate that indicates delegation to the SCF agent’s APN 
and is signed using the application’s private key. Other SCF 
agents can then use the public key from the embedded certifi- 
cate to check that signature, and can use the root certificate 
for the application’s namespace in order to check the inner 
certificate proving that the application itself really owns the 
APN initially. 

Full routes between SCF agents can be securely advertised 
by further nesting the certificates this way. This mechanism 
can be used to prove contacts have existed at one point in 
time or another, and that transitive sets of contacts have taken 
place over time, but does not show current or future proof of 
reachability. That is part of the routing/addressing system. 

XI. Directory Services 

In order to illustrate how name-to-address (N2A) binding 
directory services could operate in SCF networks we provide 
two examples. The first example is an army deployment. This 
is used to show an SCF with high degree of disconnection. The 
second example is the use of namespaces for aeronautics. The 
purpose of the aeronautics example is to show how distributed 
N2A directories are: updated, enable mobility, and enable 


use of common infrastructure while simultaneously securing 
critical infrastructure. 

A. Army Field Operations 

Figure 5 illustrates a conceptual field deployment for the 
army. Army communications is highly structured - particu- 
larly the closer one gets to the core network. In addition, 
connectivity and bandwidth increase as one moves from the 
soldier to the core. The field army hierarchy shown is of the 
form, Division (DI), Brigade (BR), Battalion (BA), Company 
(CO), Platoon (PL), and Squad (SQ). Each upper echelon is 
composed of multiple lower echelons. For example, there are 
8 to 16 soldiers in a squad, 2 to 4 squads in a platoon and 3 to 
5 platoons in a company. In our example. Companies have full 
connectivity to Battalions; Battalions have full connectivity to 
Brigades; and Brigades have full connectivity to Divisions. 

In figure 5, each rectangle from Division to Squad represents 
a SCF routing agent. For convenience, the identities of these 
SCF routing agents are provided by hierarchical names. The 
upper rectangle is Dl for Division 1. The lower middle rect- 
angle as squad echelon level is SQ4.PL1.C05.BA3.BR2.DI1, 
i.e. <Sqaud4> <Platoonl> <Company5> <Battalion3> 
<Brigade2> <Divisionl>. Such a naming system could be 
use as addressing, but care should be taken to not use appli- 
cation identifiers as the point of attachment locator (address) 
otherwise multi-homing and mobility problems will result (see 
the following aeronautics example for clarification). In the 
army example, we use a hierarchical numbering system for 
addressing with the alphanumeric names for identities. 

The Division is responsible for allocating addresses (loca- 
tion names) in the namespace 1.0. When the Brigade routing, 
BR2, attaches to Division router, Dll, BR2 sends and empty 
request for names signifying that it is requesting an address, 
or, in this case, a set of addresses. The Division allocates the 
locator name 1.2 and the Delegated-Subnetwork-Namespace 
(DSN) 1.2.* to the Brigade router, BR2. BR2 is now respon- 
sible for that DSN and passes a fraction of that down to 
the Brigade 3 router, BR3. BR3 in now responsible for DSN 
1.2.3.*. As echelon routers connect to the system, they request 
and are allocated sub-address space. Note, prior to time, 
Tl, the Platoon and Squad routers have not been allocated 
delegated-subnetwork-namespace (addresses). At time, Tl, the 
Platoon routers receive their address allocations and at time, 
T2, the Squad routers have delegated-subnetwork-namespace 

Two soldiers are represented by their identities, ID 123 and 
ID199. They have no addresses until time, T3, at which 
time they can communicate up and down within the 1.0 
namespace. At time, T4 they become disconnected. At time, 
T5, they connect to each other and can communicate over a 
link local address on the wireless connection. They can only 
communicate via applications that have been allocated and 
validated. Validation occurs using the common NSIs for those 
particular applications (see the following aeronautics example 
for clarification). At time, T6, soldier ID 123 can communicate 
with and across echelons within the 1 .0 namespace using an 
entirely new location identifier. Note, rebinding of location 
to identity occurs from bottom up. Thus, those nearest to the 
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Fig. 5. Notional Field Army Naming and Addressing 

mobile node will perceive the updates more quickly than those 
topologically further away. This is exactly what we want in a 
SCF network. Also, during times of disconnection, when, for 
instance, ID123 cannot find or connect to ID199, sending the 
containers up the tree is perfectly reasonable as one would 
expect the location of ID 199 to eventually propagate to the 
upper echelons. 

B. Aeronautical Mobile Networks 

Figure 6 illustrates and aeronautical mobile network and 
table 1 shows the B2A directory updates. This example is 
used to show: how the B2A tables get updated: how mobility 
is accommodated; and, how namespaces can be used to enable 
shared infrastructure while securing critical infrastructure. 

For this aeronautics network, we have a number of domains; 
each can have their own set of namespaces for applications. 
We also have a global routing namespace for addressing 
(location). In aeronautic networks, Air Traffic Control (ATC) is 
a critical communication system for safety of flight and safety 
of life. Airline Operation Control (AOC) is used for passenger 
information, fuel, weather, electronic flight bags and other 
applications often specific to the airlines. In future networks 


it is envisioned that ATC and AOC may be permitted to share 
the same radio links. However, ATC is always given priority 
over AOC. The other system on an aircraft is the Passenger 
Internet and Entertainment Services (PIES). This is generally 
and open network. We also have the open Internet services 
on the ground as well as the various passengers’ corporate 
networks (private networks). 

In figure 6 we show eight different N2A directories. Di- 
rectory 2 is a local, on aircraft directory. The aircraft ID is 
NX211. We assign the aircraft router the same ID. In this ex- 
ample, assume there are 5 computing systems onboard, ATC, 
AOC, and three passengers’ computers (e.g. smart phones, 
pads, laptops, etc.). ATC has one application with a UUID 
of NX211(atc). AOC has three applications: NX211(efb), 
NX211(fuel), and NX21 1 (weather). The local onboard router 
is providing pong and chess as entertainment applications to 
the passengers. Chuck and Kim have registered to play pong. 
Chuck and Larry have registered to play chess as well as access 
to the Internet. Kim will be using her corporate email system. 

While on the ground at the gate, all systems are connected 
via the AeroMAX link. AeroMAX is a shared, high-speed 
wireless link used on the airport tarmac for communication to 
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TABLE I 

Name-to-Address Bindings 



Fig. 6. Aeronautical Network 

multiple entities. Once in the air, enroute, the aircraft ATC and 
AOC can use Link-2 back to the FAA Control Center. Link-2 
is a highly reliable, low-rate link. This link is not available 
to passengers. NX211 happens to have satellite service. This 
link is available to passengers and (let us assume) it is also 
available to ATC and AOC services. At some point in the 
flight, there is a handover from link-2 (Cleveland Control 
Center) to link-4 (Chicago Control Center). 

Table I shows the N2A binding updates that occur during 
various stages of flight. At time, Tl, the onboard systems 
update their binding with the local directory, D2. Also, all 
systems are permitted to use the AeroMAX. Thus, all systems 
send binding information to Directory 4. Directory 4 then 
updates the AOC and ATC directories. At time, T2, Links 2 
and 3 are active. ATC and AOC are permitted to use both links 
with PIES is only permitted to use Link-3. The corresponding 
directly connected directories, D5 and D8 receive binding 
updates. Note that ATC and AOC are now multi-homed (i.e. 
have two or more N2A binding entries). In addition, at time, 
T2, ATC, AOC and PIES have all moved topologically. Finally, 
at T3, Link 2 is inactive and link 3 is active. Thus ATC 
and AOC binding updates show mobility from the Cleveland 
Control Center to the Chicago Control Center. 

XII. Quality-of-Service 

In the Aeronautics Networking example, we show that 
specific networks can be separated via namespaces. In this 
manner we can restrict use of various links such as links 2 
and 3 to various namespaces (here ATC and AOC. This is one 
aspect of (Quality of Service (QoS)). 

An important aspect of QoS regarding SCF networks is 
the ability to manage resources (e.g. storage, computation, 
bandwidth and power - battery life). This is critical for SCF 
systems as resources are precious. Furthermore, and inability 
to properly manage resources opens the system to denial- 
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of-service (DOS) attacks. Namespace can be used in SCF 
firewalls to control resource allocations such as: 

• What namespaces are permitted to use any of the system 
resources at all; 

• What links may be used by particular namespaces; 

• How much storage will be allocated to a particular 
namespace; and 

• The size of the container that may be accepted for 
reception. 

Note, since we can prove that containers were sent by the 
name-holder, QoS using namespaces has authentication unlike 
what the IP world offers. It is also much stronger than what 
Bundle Authentication Block (BAB) offers for DTN [22] since 
it gives proof all the way back to the source, not just to the 
previous hop. Thus, it is robust to having compromised agents 
in the middle of the network generating bogus containers. 

XIII. Conclusions 

The secure naming system presented provides a light-weight 
method for allocating and validating application names and 
locators (addresses) that could be deployed in a Store, Carry 
and Forward, normally disconnected networks. The technique 
can also be applied to fully connected networks. By ensuring 
that the application names separate from the location names, 
the system readily handles multi-homing and mobility. 

Our system could be an enabling technology for the aero- 
nautics networks vastly simplifying operations and manage- 
ment. For instance, every infrastructure provider can maintain 
its own namespaces for management of its equipment. Since 
these are not exposed to the users, most security threats to the 
infrastructure instantly disappear. 

Infrastructure providers that wish to confederate for the 
purposes of creating a routable address space between them 
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can do so, and those routable addresses still do not expose their 
management and control planes to one another. Mobile users 
sharing NSI certificates for that address space, can roam to 
any provider that’s also part of it, without any pre-existing trust 
relationships, and obtain addresses. If they need to be globally 
reachable themselves, they can use their own namespaces 
above, created for specific domains ( ATC, AOC, PIES) and 
allowing applications from all domains to utilize the same 
infrastructure yet be completely isolated from one another 
except for sharing bandwidth. Such techniques also apply to 
securing “Critical Infrastructure Networking’’. There will be 
no fear of accidentally leaking routes, because the namespaces 
have been factored out, access to names is secured, and proof 
of ownership is verified. 
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Appendix 
List of Acronyms 


AES 

Advanced Encryption Standard 

AOC 

Airline Operation Control 

API 

Application Program Interface 

APN 

Application Process Name 

ATC 

Air Traffic Control 

CRL 

Certificate Revocation List 

CTR 

Counter encryption mode 

DAN 

Distributed Application Names 

DHT 

Distributed Hash Table 

DNS 

Domain Name System 

DSN 

Delegated-Subnetwork-Namespace 

DTN 

Delay /Disruption/Disconnection Tolerant 
Networking 

ECC 

Elliptic Curve Cryptography 

ECDH 

Elliptic Curve Diffie-Hellman 

ECDSA 

Elliptic Curve Digital Signature Algorithm 

GUA 

Global Unique Address 

HPoN 

Hierarchical Proof-of-Name 

IANA 

Internet Assigned Numbers Authority 

IEEE 

Institute of Electrical and Electronics Engineers 

IP 

Internet Protocol 

IPv6 

Internet Protocol version 6 

JSON 

JavaScript Object Notation 

MAC 

Media Access Control 

MANET 

Mobile Ad Hoc Network 

N2A 

name-to-address 

NAT 

Network Address Translator 

NSA 

National Security Agency 

NSI 

Name Space Identifier 

OS 

Operating System 

PIES 

Passenger Internet and Entertainment Services 

PKI 

Public Key Infrastructure 

PoN 

Proof-of-Name 

PVI 

Personal Identify Verification 

QoS 

Quality of Service 

SCF 

Store, Carry and Forward 

SHA 

Secure Hash Algorithm 

SF 

Store and Forward 

URL 

Uniform Resource Locator 

UUID 

Universally Unique Identifiers 

VPN 

Virtual Private Network 
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